Deploying

Alright, so you've created a local project, and you want to show it to the world! Let's learn how to ship it.

Working with full-stack frameworks like Next can be a bit tricky. We can't really use “off the shelf” hosting companies like GoDaddy; these services only work if you have a bunch of static HTML/CSS/JS files, but with Next, we need a live-running Node.js server, so we can do our on-demand server side rendering.

A few years ago, this was a really daunting challenge. Essentially, we'd need to provision a Linux server, set up SSH, get an SSL certificate, learn how to configure nginx, figure out a deployment strategy, the list goes on.

Fortunately, it's way way easier nowadays. Several companies have made it their mission to make this stuff as simple as possible.

Here are some examples of these sorts of companies:

• Vercel (opens in new tab)
• Netlify (opens in new tab)
• Render (opens in new tab)
• Heroku (opens in new tab)

When I first created this lesson, Next’s App Router was still in beta, and Vercel offered by far the best experience. Fortunately, other providers have caught up. Deploying on Netlify, for example, is just as seamless as it is on Vercel!

For now, the instructions on this page use Vercel, but the process is very similar for other hosting providers, and I actually think my main recommendation these days would be to use Netlify.

I should also note: from mid-2022 to December 2024, Vercel was sponsoring my account. This means that I got to use their services for free. This saved me about US$50-100/month.

Before we go through the step-by-step process of deploying with Vercel, I want to quickly answer the question: Should we use a managed hosting provider, or do it ourselves?

Vercel, Netlify, Render, and Heroku are all examples of “managed” hosting providers. These services offer a layer of abstraction that sits above the actual hardware.

We don't have to use one of these services, we could manage the hosting ourselves. The classic way to do this is to rent a VPS? using a service like DigitalOcean or Linode, and set everything up from scratch. A more modern alternative is to use a cloud infrastructure provider like AWS Lambda.

But these options are hard. It's an entire engineering discipline ("DevOps"). Speaking as someone who has gone the “classic” route before, there are so many things we have to consider. Things like ongoing maintenance (updating software to patch security vulnerabilities) and scaling (provisioning additional servers and a load balancer).

If we use Amazon Web Services or Google Cloud, we can avoid some of this pain, but these services are notoriously difficult to learn. There are “AWS Certification” programs that take months to complete.

Modern managed providers like Vercel/Netlify are built on top of cloud infrastructure providers like AWS and Google Cloud. They wrap over these complex services and provide a super-user-friendly way to use them. That's their main value proposition.

They do charge for this service, of course. At scale, services like Vercel/Netlify charge more than the underlying cloud infrastructure providers like AWS. And, in general, AWS / Google Cloud are more expensive than managing your own provisioned server.

That said, almost every provider has a free “hobby” tier, and these tiers are usually generous enough for most non-professional use cases. And even for commercial projects, the costs can be surprisingly low.

For example, joshwcomeau.com (opens in new tab) receives about 350,000 page views a month, consuming about 900GB of bandwidth. This just fits within Vercel's $20 “Pro” plan, which offers 1TB of monthly bandwidth. It's remarkable to me that a blog with hundreds of thousands of hits can cost only $20/month.

Alright, enough jibber-jabber! Let's get to work.

First, we need a project we want to deploy. I'm going to use the “hello-next” project (opens in new tab) we saw earlier in the course.

You'll need your own copy of this project on Github. The easiest way to accomplish this is to “fork” it. Click this little button:

You should wind up with your own personal copy of the project:

This is the project I'll use in this lesson, but you should feel free to use any React project you want! It really doesn't matter, the process is the same regardless.

Now that we have our project, we're ready to get started.

Visit the signup page (opens in new tab), and go through the flow. You can create a “hobby” account, and enter your name:

Next, you'll need to connect your Git provider account. This is important, since Vercel uses a Git-based flow for deploying.

You should pick whichever provider you typically use. For most of us, that's Github:

Clicking one of these buttons will open a pop-up. We need to grant Vercel the authority to interact with our Git projects:

Personally, I grant Vercel access to all repositories, because I don't want to have to fiddle with permissions every time I want to deploy a new project. If you have privacy concerns, however, feel free to limit Vercel's access by clicking "Only select repositories", and selecting the project you'd like to deploy.

Once we've authorized Vercel, we'll be asked to confirm a phone number, and then finally, we make it to the “New Project” screen:

If you don't see the repository you wish to deploy, you can search for it. Once found, click “Import”.

On the next screen, you'll be asked to configure your project. You shouldn't need to change anything here. Vercel should identify that this is a Next.js project, and make all of the necessary configurations for us.

Click “Deploy”:

Vercel will start building our application:

Here's what's actually happening here: Vercel is running the build NPM script we saw in the previous lesson. It generates all of the files needed to serve our application.

Then, it pushes that code to its cloud infrastructure. Under the hood, Vercel uses providers like Amazon Web Services and Google Cloud Services.

After a minute or so, this work is complete, and we get some celebratory confetti:

Our app is live!

If we click “Continue to Dashboard”, we see the main view for this project. This is the home base for this project on Vercel:

Vercel generates a root URL for all projects. In my case, the URL is hello-next-liard.vercel.app (opens in new tab). We can click the “Visit” link to see it live in-browser.

Our project is live! 🌈

Let's talk about how we deploy changes to our project.

Because we've synced our Vercel project with our Github repository, our application will automatically be updated whenever we push changes to Github.

As a silly example, suppose I make the following change:

function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        {children}
+        <footer>Copyright Josh Inc.</footer>
      </body>
    </html>
  );
}

I create a new Git commit with this change. And push it to Github. Vercel will automatically start rebuilding the project:

If you're already using Git to manage your project, it's zero extra steps to deploy your changes. Whenever you push your code to Github, Vercel will rebuild your application, and the new version will be up within a minute or two.

Let's talk about one of the coolest little things that Vercel does, right out of the box.

As part of the initial configuration, we told Vercel the name of our primary Git branch. By default, this is main (and sometimes master, on older projects). When we commit changes to this branch, Vercel will deploy them for the world to see.

But check out what happens when we push code to a different branch:

The scenario here is that I created a new branch, pink-footer. This branch changes the text color of the footer to hotpink.

Whenever we update a non-primary branch on Github, Vercel spins up a new “preview deploy”. This deploy gives us a shareable URL we can use to preview this change. It doesn't change what anyone sees on the main domain, but it gives us a convenient preview of what it'll look like!

In this case, the custom domain is hello-next-git-pink-footer-josh-and-co.vercel.app. If I visit this URL, I see my work-in-progress pink footer:

This is a really handy feature when working on a team. We can generate preview deploys so that the design team can get an early peek at what our implementation looks like.

Vercel also conveniently shares information about the preview deploy whenever we open a pull request on Github:

This has become a fairly common feature amongst modern hosting services; Netlify does something similar.

As we've seen, Vercel generates a domain we can use, like hello-next-liard.vercel.app. This is convenient for hobby projects, but we probably don't want to launch a serious project with this domain!

Suppose you own a domain you want to use, hello-next-josh.com. Let's look at how to wire it up so that this domain points to our new project.

First, head to the main dashboard page. You can get there by clicking your name in the top-left corner:

Then, visit the “Domains” page, and click “Add”:

The flow beyond this point should be pretty self-explanatory. Select your project from the list, and enter in the domain you wish to use.

After confirming, you should wind up seeing something like this:

It says that there's “Invalid Configuration”, but that's because we haven't yet edited our domain records so that this domain resolves to Vercel's servers.

Every registered domain has a set of records that specify where requests should go. We need to edit these records so that when someone visits hello-next-josh.com, they'll wind up making a request to Vercel's server.

The instructions for editing your domain's records will vary from one registrar to another. If you google "edit DNS [provider name]", you should find some instructions.

Edit the domain's A record so that it points to the IP address specified. In my case, the IP is 76.76.21.21, though you might get a different value from Vercel.

Within a few hours of making this change, your domain should now point to your Vercel project!

Vercel will automatically generate and apply an SSL certificate. Your site will use HTTPS without you needing to do anything at all. ✨